GH-577: Use JVM proxy settings in Netty client - #1027
Conversation
This comment has been minimized.
This comment has been minimized.
|
As I'm close to release Arrow Java 19.0.0, I will consider this PR for 20.0.0. |
|
@jbonofre yeah that makes sense, this one is still a draft as I have not finished work on it, I will ping you once I finish the PR. Should be ready in the next couple of days. |
ef9e0c5 to
1e44df0
Compare
|
While the fix was in the Let me know if it's worth it to expand the testing surface with a unit test closer to the place of the bug fix. |
|
Can we rebase? It seems CI did not trigger |
1e44df0 to
dcfa5ef
Compare
|
It seems all workflows time out here, even after a retry. |
|
@lidavidm Thanks for the ping. I rebased all PRs. |
Do you guys need help with the CI? I was going to look into some CI stuff on Arrow Go, but given that we have a release here I can jump in before I move to that. Edit- I synced with JB and I saw that he is already on it. I'll continue with the protocol change implementation in other languages to have feature parity. |
3 participants
What's Changed
The Flight SQL JDBC driver ignored JVM proxy settings (
-Dhttps.proxyHost,-Dhttps.proxyPort). Connections would always go directly to the target host, bypassing any configured proxy.Switched to
NettyChannelBuilder.forAddress(host, port)for the TCP-based schemes. This causes gRPC to go throughProxySelector, which picks up the standard JVM proxy properties.Are these changes tested?
Yes.
Added a test to
ConnectionTestthat installs a recordingProxySelectoras the JVM default, opens a JDBC connection, and asserts thatProxySelector.select()was called. This directly validates that the driver participates in JVM proxy detection without requiring a real proxy server.This change was created with AI assistance (Claude Code). All lines were manually reviewed by a human. The output is not copyrightable subject matter.
Closes #577.